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(1) Real Party in Interest 

The real party in interest is Microsoft Corporation, the assignee of all right, 
title and interest in and to the subject invention. 

(2) Related Appeals and Interferences 

Appellant is not aware of any other appeals, interferences, or judicial 
proceedings which will directly affect, be directly affected by, or otherwise have a 
bearing on the Board's decision to this pending appeal. 

(3) Status of Claims 

Claims 1-25 stand rejected and are pending in the Application. Claims 1- 
25 are set forth in the Appendix of Appealed Claims on page 23. 

(4) Status of Amendments 

A final Office Action, dated January 24, 2007, was sent by the Office. 
A response to the final Office Action was filed April 16, 2007. The 
response included proposed amendments for claims 10-12. 
A Notice of Appeal was filed on April 20, 2007. 

An Advisory, dated June 5, 2007, was sent by the Office. In the Advisory 
Action, the Office indicated that the proposed amendments in the response (filed 
April 16, 2007) would not be entered because they were not deemed to place the 
application in better form for appeal. 
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(5) Summary of Claimed Subject Matter 

A concise explanation of each of the independent claims is included in this 
Summary section, including specific reference characters, if any. These specific 
reference characters are examples of particular elements of the drawings for 
certain embodiments of the claimed subject matter and the claims are not limited 
to solely the elements corresponding to these reference characters. 

With regard to claim 1, a method comprising: receiving a command from a 
decoder application (Fig. 2 (160A-N)) at an application program interface (API) 
(Fig. 2 (104)), wherein the API is configured to facilitate the use of a plurality of 
different multimedia accelerators (Fig. 2 (174A-N)) with the decoder application 
(Page 15, lines 2-18; Fig. 2 (104, 160A-N, 174 A-N)); and generating one or more 
filter control command data structures (Fig. 2 (204); Page 52, line 19 through page 
53, line 2; Fig. 3 (300)), recognizable by a communicatively coupled accelerator 
including one or more parameters which, when received by the accelerator, affects 
one or more filter settings of the accelerator based, at least in part, on the content 
of the received command (Page 23, lines 9-25; Fig. 2 (204)). 

With regard to claim 12, a storage medium (Fig. 10 (1000)) comprising a 
plurality of executable instructions (Fig. 10 (1002)) which, when executed, 
implement an application program interface (API) (Fig. 10 (1004)) to dynamically 
generate one or more filter control command data structures in response to a 
command received from a decoder application (Fig. 2 (204); Page 52, line 19 
through page 53, line 2; Fig. 3 (300)), wherein the one or more filter control 
command data structure (s) include one or more parameters which, when received 
by a communicatively coupled accelerator, effect one or more filter settings on the 



4 



Application No. 09/839,679 



accelerator in accordance with the received command (Page 23, lines 9-25; Fig. 2 
(204); Page 62, lines 1-16; Fig. 10 (1000-1004)), wherein the API is not specific to 
any particular multimedia application and/or multimedia accelerator (Page 62, 
lines 11-12; page 15, lines 17-18). 

With regard to claim 18, a computing system comprising: a decoder 
application (Fig. 2 (160 A-N)) to process received media content; and an operating 
system (Fig. 1 (158)) including an application program interface (API) (Fig. 1 
(104); Fig 2 (104)), support the media processing, wherein the API generates one 
or more filter control commands including one or more parameters (Fig. 2 (204); 
Page 52, line 19 through page 53, line 2; Fig. 3 (300)) which, when received by a 
communicatively coupled media processing accelerator, effect one or more filter 
settings of the accelerator in accordance with a command received from the 
decoder (Page 23, lines 9-25; Fig. 2 (204)), wherein the decoder application is 
configured to iteratively issue configuration commands (Page 55, lines 1-4; Fig. 5 
(502)) reflecting various alternative degrees and methods of decoding acceleration 
capability until choosing one that is acceptable to both the decoder application and 
the accelerator (Page 55, lines 1-10; Fig. 5 (502-508)). 

(6) Grounds of Rejection to be Reviewed on Appeal 

Claims 10-12 stand rejected under 35 U.S.C. § 101 "because the claims do 
not meet the 35 U.S.C. requirements (the claims have improper language 
regarding the storage medium)." 
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Claims 1-25 stand rejected under 35 U.S.C. § 103(a) as being obvious over 
U.S. Patent No. 6,744,472 to Maclnnis in view of U.S. Patent No. 6,725,279 to 
Sriram. 

(7) Argument 

A. The rejections under 35 U.S.C. §101 fail because the Office has failed 
to establish a prima facie case of unpatentability. 

Applicant respectfully submits that the Office has not established a prima 
facie case of unpatentability. Specifically, the Office has not identified or 
explained why claims 10-12 are directed to an abstract idea with no practical 
application. Instead, the Office has merely stated that the claims are rejected 
"because the claims do not meet the 35 U.S.C. 101 requirements (the claims have 
improper language regarding the computer-readable media)." The Office then 
directs the Applicant's attention to the USPTO Interim Guidelines for Examination 
of Patent Applications for Patent Subject Matter Eligibility Annex IV". 

Accordingly, the Office has provided no explanation or justification for this 
rejection. Applicant respectfully reminds the Office that the Office has the burden 
of setting forth a prima facie case of unpatentability, (see e.g. MPEP 2106 
IV(C)(3)(D)). In this regard, this section of the MPEP makes it clear that it is only 
after the Office is able to "identify and explain in the record the reasons why a 
claim is for an abstract idea with no practical application" that "the burden shifts 
to the applicant to either amend the claim or make a showing of why the claim is 
eligible for patent protection." (Id.). Applicant respectfully submits that simply 
stating that the claims are rejected "because the claims do not meet the 35 U.S.C. 



6 



Application No. 09/839,679 



101 requirements" simply reiterates that the claims are rejected and fails to 
identify or explain why the claim is rejected. Accordingly, Applicant respectfully 
requests that these rejections be withdrawn. 

B. The rejections under 35 U.S.C. §103(a) over Maclnnis and Sriram fail 
because the Office has failed to establish a prima facie case of 
obviousness. 

Applicant respectfully submits that the Office has not established a prima 
facie case of obviousness. The discussion below proceeds as follows. First, a 
section entitled "The § 103 Standard" is provided which describes the criteria that 
must be met in order to establish a prima facie case of obviousness. Second, a 
section entitled "The Claims" is provided which presents Applicant's reasoning as 
to why the Office has not met these criteria. 

The §103 Standard 

To establish a prima facie case of obviousness, three basic criteria must be 
met. First, there must be some suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the reference or to combine reference teachings. Second, there 
must be a reasonable expectation of success. Finally, the prior art reference (or 
references when combined) must teach or suggest all the claim limitations. The 
teaching or suggestion to make the claimed combination and the reasonable 
expectation of success must both be found in the prior art and not based on 
Applicant's disclosure. In re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 
1991). 
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The Claims 

Claim 1 recites a method comprising: 

• receiving a command from a decoder application at an application 
program interface (API), wherein the API is configured to facilitate 
the use of a plurality of different multimedia accelerators with the 
decoder application; and 

• generating one or more filter control command data structures, 
recognizable by a communicatively coupled accelerator including 
one or more parameters which, when received by the accelerator, 
affects one or more filter settings of the accelerator based, at least in 
part, on the content of the received command. 

In making out the rejection of this claim, the Office argues that its subject 
matter is rendered obvious in view of Maclnnis and Sriram. Specifically, the 
Office relies on Fig. 2 (item 50) of Maclnnis for disclosing "receiving a command 
from a decoder application." In this regard, the Office argues "the decoder 
application is the video decoder". The Office then relies on Fig. 2 and Column 57 
(lines 21-37) of Maclnnis as disclosing "generating one or more filter control 
command data structures, recognizable by a communicatively coupled accelerator 
including one or more parameters which, when received by the accelerator, affects 
one or more filter settings of the accelerator". In this regard, the Office argues 
"the filter parameters are the blending, scaling, blitting, and filling, [and] the 
accelerator is the graphics accelerator." Unfortunately, the Office does not address 
the claim language "based, at least in part, on the content of the received 
command". Finally, while the Office argues that Maclnnis inherently discloses an 
application interface that would be necessary for it to correctly operate, it 
nevertheless relies on Columns 4 (lines 48-54), 7 (lines 10-14) and 8 (lines 1-14) 
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of Sriram for disclosing an API that is "configured to facilitate the use of a 
plurality of different multimedia accelerators with the decoder application". The 
Office argues that one would have been motivated to combine the teachings of 
these references "in order to obtain an apparatus that is more versatile by being 
able to perform complex operations." 

Applicant respectfully traverses this rejection and submits that the Office 
has not established a prima facie case of obviousness. 

First, Applicant submits that the references do not collectively disclose all 
of the subject matter of this claim. For example, Applicant fails to understand how 
Item 50 in Fig. 2 of Maclnnis (labeled "Video Decoder") discloses or suggests 
"receiving a command from a decoder application..." as claimed. Instead, as far 
as Applicant can discern, Item 50 simply discloses a video decoder component of 
an integrated circuit (integrated circuit 10) that receives video signals which it 
digitizes and processes into a format that can be used by a video scaler. As such, 
Applicant is left without any explanation as to how Item 50 in Maclnnis is relevant 
to the claimed subject matter. 

Furthermore, it appears that the Office has forgotten the claim language 
"...based, at least in part, on the content of the received command." As such, the 
Office's reliance on the Graphics Accelerator 64 in Maclnnis is misplaced because 
nothing indicates "...one or more parameters which, when received by the 
accelerator, affects one or more filter settings of the accelerator based, at least in 
part, on the content of the received command^ (emphasis added). Indeed, the 
only commands that are received by the accelerator in Maclnnis appear to be 
commands it receives directly from a CPU (see Fig. 37 and Column 57 (lines 46- 
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47). As such, Applicant is left without any explanation as to how the Graphics 
Accelerator 64 in Maclnnis is relevant to the claimed subject matter. 

In addition, the integrated circuit system of Maclnnis simply does not 
inherently disclose an application interface (API) that would be necessary for it to 
correctly operate, as the Office contends. In this regard, Sriram does not disclose 
or suggest an API that is configured to "facilitate the use of a plurality of different 
multimedia accelerators with the decoder application" as claimed. Instead, the 
monitor processor in Sriram is part of the decoder's system memory and is merely 
responsible for splitting picture decoding into multiple sub-processes based upon 
one of two schemes to maximize scalability and efficiency (see e.g. Sriram, 
Column 7, lines 49-50 and Column 8, lines 19-21). 

Second, the Office's stated motivation "to obtain an apparatus that is more 
versatile by being able to correctly and effectively facilitate the use between 
multiple processors in a system" is too general and could serve as the basis for 
making any modification to Maclnnis. Furthermore, this stated motivation is 
simply inapplicable to Maclnnis which is directed to a graphics integrated circuit 
chip for controlling a television display which includes a bus to communicate with 
peripheral components on a system, such as a CPU. (e.g., see Maclnnis Column 3 
(lines 40-45)). In other words, the Office's stated motivation is simply not 
germane to Maclnnis which is concerned with specific operations which are 
unrelated to facilitating the use between multiple processors in a system. 
Accordingly, Applicant respectfully submits that that a person of ordinary skill in 
the art, having common sense at the time of the invention, would not have 
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reasonably looked to Sriram to solve a problem that is not applicable or relevant to 
Maclnnis. 

Third, modifying the integrated chip structure of Maclnnis with the 
hierarchically regimented decoding system of Sriram would impermissibly render 
Maclnnis unsatisfactory for its intended purpose (see MPEP 2143.01). 
Specifically, and by way of example and not limitation, Maclnnis is directed to a 
graphics display system that "accepts video input signals that include analog 
video signals..." (e.g., see Maclnnis, Column 3 (lines 49-50)) (emphasis added). 
In this regard, the video decoder of Maclnnis (see Maclnnis Fig. 2, item 50) is 
specifically configured to process analog video signals. In contrast, the system of 
Sriram is limited to processing digital video signals that are in MC (motion 
compensation) - DCT (discrete cosine transform) format. As such, modifying 
Maclnnis with the system of Sriram would appear to render Maclnnis 
unsatisfactory for its intended purpose of providing a graphics display system 
accepting both analog and digital video signals. Accordingly, Applicant 
respectfully submits that that a person of ordinary skill in the art, having common 
sense at the time of the invention, would not have reasonably modified Maclnnis 
with the teachings of Sriram because doing so would have rendered Maclnnis 
incapable of accepting "video input signals that include analog video signals. . ." 

In view of the above discussion, the Office has not established a prima 
facie case of obviousness. Accordingly, for at least this reason, Applicant 
traverses this rejection and submits that this claim is allowable. 

Claims 2-11 depend from claim 1 and are allowable as depending from an 
allowable base claim. These claims are also allowable for their own recited 
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features which, in combination with those recited in claim 1, are neither disclosed 
nor suggested in the references of record, either singly or in combination with one 
another. 

In addition, regarding claim 3, the Office argues that Fig. 28 of Maclnnis 
discloses "wherein the filter is a post-processing filter." Applicant, after reviewing 
Fig. 28, fails to see how this subject matter is disclosed or suggested. Specifically, 
Fig. 28 deals with blending by the video compositor, not the accelerator, (see e.g. 
Maclnnis, Column 44, lines 23-38 and Fig. 2). Accordingly, Applicant submits 
that the Office's reliance on this figure is misplaced. 

In addition, regarding claim 4, the Office argues that the subject matter of 
this claim is disclosed on Column 4 (lines 29-31) of Richter. Furthermore, the 
Office states that "filters and prediction references are well known within the 
environment of encoders and decoders". Applicant respectfully disagrees. First, 
this excerpt simply does not disclose: "wherein output data subsequent to the 
application of a post-processing filter are used as prediction references", as 
claimed. Second, the Office has not substantiated its claim that filters and 
prediction references were well known. This excerpt from Column 4 is 
reproduced below for the Office's convenience: 

This architecture is particularly used to implement very complex 
multimedia processing configurations using, for example, echo 
suppressors or encoding or decoding blocks with a very simple application 
interface. 

In addition, regarding claims 6-7, the Office cites Column 4 (lines 40-51) of 
Maclnnis and argues: "the strength parameter is the scaling". Applicant 
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respectfully disagrees and submits that the Office has mischaracterized the 
Maclnnis reference. Specifically, this cited excerpt merely discusses a video 
scaler that is responsible for scaling video stream input. This simply has nothing 
to do, whatsoever, with "a strength parameter to control an amount of filter applied 
by a receiving filter" or any other parameter(s) "which, when received by the 
accelerator, affects one or more filter settings of the accelerator", as claimed. 

Furthermore, even if "the strength parameter was the scaling", which it is 
not, the Office appears to have forgotten that it relies (albeit inappropriately) on 
the "blending, scaling, blitting, and filling" of Maclnnis's graphics accelerator, 
not its video scaler, for disclosing "the filter parameters". As such, the scaling 
performed by the video scaler in Maclnnis could not possibly disclose the strength 
parameter recited in this claim. In addition, even a cursory glance at Fig. 2 of 
Maclnnis illustrates that the Video Scaler 52 is completely separate from the 
accelerator 64 and performs a completely different function(s). 

Claim 12 recites one or more computer-readable media having computer- 
readable instructions stored thereon which, when executed by a computer, 
implement an application program interface (API) to dynamically generate one or 
more filter control command data structures in response to a command received 
from a decoder application, wherein the one or more filter control command data 
structure(s) include one or more parameters which, when received by a 
communicatively coupled accelerator, effect one or more filter settings on the 
accelerator in accordance with the received command, wherein the API is not 
specific to any particular multimedia application and/or multimedia accelerator. 
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In making out the rejection of this claim, the Office relies on the same 
argument it proffered in rejecting claim 1 . Applicant respectfully traverses this 
rejection and submits that the Office has not established a prima facie case of 
obviousness. 

First, Applicant submits that the references do not collectively disclose all 
of the subject matter of this claim. For example, Applicant fails to understand how 
Item 50 in Fig. 2 of Maclnnis (labeled "Video Decoder") discloses or suggests "a 
command received from a decoder application" as claimed. Instead, as far as 
Applicant can discern, Item 50 simply discloses a video decoder component of an 
integrated circuit (integrated circuit 10) that receives video signals which it 
digitizes and processes into a format that can be used by a video scaler. As such, 
Applicant is left without any explanation as to how Item 50 in Maclnnis is even 
relevant to the claimed subject matter. 

Furthermore, it appears that the Office has forgotten the claim language 
"...in accordance with the received command". As such, the Office's reliance on 
the Graphics Accelerator 64 in Maclnnis is misplaced because nothing indicates 
"wherein the one or more filter control command data structure(s) include one or 
more parameters which, when received by a communicatively coupled accelerator, 
effect one or more filter settings on the accelerator in accordance with the 
received command", (emphasis added). Indeed, as noted above, the only 
commands that are received by the accelerator in Maclnnis appear to be 
commands it receives directly from a CPU. As such, Applicant is left without any 
explanation as to how the Graphics Accelerator 64 in Maclnnis is relevant to the 
claimed subject matter. 
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In addition, the Office appears to have forgotten the claim language "...in 
response to a command received from a decoder application". As such, the 
Office's reliance on Fig. 2 and Column 57 (lines 21-37) of Maclnnis is misplaced 
because even if the is excerpt did disclose "one or more filter control command 
data structures", which it does not, nothing indicates that that a structure is 
generated in response to a command received from a decoder application. Indeed, 
as noted above, the only commands that Maclnnis indicates are received by the 
accelerator are commands it receives directly from a CPU. As such, Applicant is 
left without any explanation as to how Fig. 2 and Column 57 (lines 21-37) of 
Maclnnis are relevant to the claimed subject matter. 

Finally, as noted above, the integrated circuit system of Maclnnis simply 
does not inherently disclose an application interface (API) that would be necessary 
for it to correctly operate, as the Office contends. Furthermore, in this regard, 
Sriram does not disclose or suggest an API that is configured to "facilitate the use 
of a plurality of different multimedia accelerators with the decoder application" as 
claimed. Instead, the monitor processor in Sriram is part of the decoder's system 
memory and merely splits picture decoding into multiple sub-processes. 

Second, as noted above, the Office's stated motivation "to obtain an 
apparatus that is more versatile by being able to correctly and effectively facilitate 
the use between multiple processors in a system" is too general and could serve as 
the basis for making any modification to Maclnnis. Furthermore, this stated 
motivation is not even applicable to Maclnnis which is directed to a graphics 
integrated circuit chip for controlling a television display which includes a bus to 
communicate with peripheral components on a system, such as a CPU. 
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Accordingly, Applicant respectfully submits that that a person of ordinary skill in 
the art, having common sense at the time of the invention, would not have 
reasonably looked to Sriram to solve a problem that is not applicable or relevant to 
Maclnnis. 

Third, as noted above, modifying the integrated chip structure of Maclnnis 
with the hierarchically regimented decoding system of Sriram would 
impermissibly render Maclnnis unsatisfactory for its intended purpose of 
providing a graphics display system accepting analog video signals. Accordingly, 
Applicant respectfully submits that that a person of ordinary skill in the art, having 
common sense at the time of the invention, would not have reasonably modified 
Maclnnis wit the teachings of Sriram because doing so would have rendered 
Maclnnis incapable of accepting "video input signals that include analog video 
signals..." 

In view of the above discussion, the Office has not established a prima 
facie case of obviousness. Accordingly, for at least this reason, Applicant 
traverses this rejection and submits that this claim is allowable. 

Claims 13-17 depend from claim 12 and are allowable as depending from 
an allowable base claim. These claims are also allowable for their own recited 
features which, in combination with those recited in claim 12, are neither disclosed 
nor suggested in the references of record, either singly or in combination with one 
another. 

In addition, regarding claim 17, the Office cites Column 4 (lines 40-51) of 
Maclnnis and argues: "the strength parameter is the scaling". Applicant 
respectfully disagrees and submits that the Office has mis characterized the 



16 



Application No. 09/839,679 



Maclnnis reference. Specifically, this excerpt merely discusses a video scaler that 
is responsible for scaling video stream input. This simply has nothing to do, 
whatsoever, with "a strength parameter to control an amount of filter applied by a 
receiving filter" or any other parameter(s) "which, when received by the 
accelerator, affects one or more filter settings of the accelerator", as claimed. 

Furthermore, even if "the strength parameter was the scaling", which it is 
not, the Office appears to have forgotten that it relies (albeit inappropriately) on 
the "blending, scaling, blitting, and filling" of Maclnnis's graphics accelerator, 
not its video scaler, for disclosing "the filter parameters". As such, the scaling 
performed by the video scaler in Maclnnis could not possibly disclose the strength 
parameter recited in this claim. In addition, even a cursory glance at Fig. 2 of 
Maclnnis illustrates that the Video Scaler 52 is completely separate from the 
Graphics Accelerator 64 and performs a completely different function(s). 

Claim 18 recites a computing system comprising: 

• a decoder application to process received media content; and 

• an operating system including an application program interface 
(API), support the media processing, wherein the API generates one 
or more filter control commands including one or more parameters 
which, when received by a communicatively coupled media 
processing accelerator, effect one or more filter settings of the 
accelerator in accordance with a command received from the 
decoder, wherein the decoder application is configured to iteratively 
issue configuration commands reflecting various alternative degrees 
and methods of decoding acceleration capability until choosing one 
that is acceptable to both the decoder application and the accelerator. 



In making out the rejection of this claim, the Office relies on the same 
argument it proffered in rejecting claim 1. In addition, the Office argues that 



17 



Application No. 09/839,679 



Columns 5 (lines 58-67) and 12 (lines 59-63) of Sriram disclose "wherein the 
decoder application is configured to iteratively issue configuration commands 
reflecting various alternative degrees and methods of decoding acceleration 
capability until choosing one that is acceptable to both the decoder application and 
the accelerator". 

Applicant respectfully traverses this rejection and submits that the Office 
has not established a prima facie case of obviousness. 

First, as discussed above, Applicant submits that the references do not 
collectively disclose all of the subject matter of this claim. For example, 
Applicant fails to understand how Item 50 in Fig. 2 of Maclnnis (labeled "Video 
Decoder") discloses or suggests "a command received from a decoder application" 
as claimed. Instead, as far as Applicant can discern, Item 50 simply discloses a 
video decoder component of an integrated circuit (integrated circuit 10) that 
receives video signals which it digitizes and processes into a format that can be 
used by a video scaler. As such, Applicant is left without any explanation as to 
how Item 50 in Maclnnis is even relevant to the claimed subject matter. 

Furthermore, it appears that the Office has forgotten the claim language "... 
in accordance with a command received from the decoder". As such, the Office's 
reliance on the Graphics Accelerator 64 in Maclnnis is misplaced because nothing 
indicates "... one or more filter control commands including one or more 
parameters which, when received by a communicatively coupled media processing 
accelerator, effect one or more filter settings of the accelerator in accordance with 
a command received from the decoder, (emphasis added). Indeed, as noted 
above, the only commands that are received by the accelerator are commands it 
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receives directly from a CPU. As such, Applicant is left without any explanation 
as to how the Graphics Accelerator 64 in Maclnnis is relevant to the claimed 
subject matter. 

In addition, with respect to Columns 5 and 12 of Sriram, Applicant submits 
that the Office has mischaracterized these excerpts. Specifically, these portions 
simply have nothing to do with a decoder application that is "configured to 
iteratively issue configuration commands reflecting various alternative degrees 
and methods of decoding acceleration capability until choosing one that is 
acceptable to both the decoder application and the accelerator." (emphasis 
added). These excerpts are reproduced below for the Office's convenience: 

Data structures are one component of the invention. Data structures for 
different block communication and parameter passing have been chosen 
according to the bit stream hierarchy. Several factors were considered in 
determining the organization of these parameters. Some of the factors are: (1) 
implementing video decoding using multiple processes efficiently; (2) 
efficient argument passing between different compute blocks; (3) 
computational efficiency; (4) efficient data flow (minimal data replication); 
and (5) good data cache effects. 

Any given processing unit (for example, Motion Compensation) needs only a 
subset of these parameters. A Macroblock structure is defined in such a way 
that all the parameters needed for Macroblock processing can be found in the 
MB data structure. 



The Office's only argument with respect to these excerpts is to state 
"wherein the configuration commands is the parameter passing". Applicant 
respectfully submits that this explanation is insufficient because it fails to account 
for all of the language of this claim element (i.e., the Office's explanation ignores 
"...reflecting various alternative degrees and methods of decoding acceleration 
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capability until choosing one that is acceptable to both the decoder application and 
the accelerator.".) 

Finally, as noted above, the integrated circuit system of Maclnnis simply 
does not inherently disclose an application interface (API) that would be necessary 
for it to correctly operate, as the Office contends. Furthermore, in this regard, 
Sriram does not disclose or suggest an API that is configured to "facilitate the use 
of a plurality of different multimedia accelerators with the decoder application" as 
claimed. Instead, the monitor processor in Sriram is part of the decoder's system 
memory and merely splits picture decoding into multiple sub-processes. 

Second, as noted above, the Office's stated motivation "to obtain an 
apparatus that is more versatile by being able to correctly and effectively facilitate 
the use between multiple processors in a system" is too general and could serve as 
the basis for making any modification to Maclnnis. Furthermore, this stated 
motivation is not even applicable to Maclnnis which is directed to a graphics 
integrated circuit chip for controlling a television display which includes a bus to 
communicate with peripheral components on a system, such as a CPU. 
Accordingly, Applicant respectfully submits that that a person of ordinary skill in 
the art, having common sense at the time of the invention, would not have 
reasonably looked to Sriram to solve a problem that is not applicable or relevant to 
Maclnnis. 

Third, as noted above, modifying the integrated chip structure of Maclnnis 
with the hierarchically regimented decoding system of Sriram would 
impermissibly render Maclnnis unsatisfactory for its intended purpose of 
providing a graphics display system accepting both analog and digital video 
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signals. Accordingly, Applicant respectfully submits that that a person of ordinary 
skill in the art, having common sense at the time of the invention, would not have 
reasonably modified Maclnnis wit the teachings of Sriram because doing so would 
have rendered Maclnnis incapable of accepting "video input signals that include 
analog video signals. . ." 

In view of the above discussion, the Office has not established a prima 
facie case of obviousness. Accordingly, for at least this reason, Applicant 
traverses this rejection and submits that this claim is allowable. 

Claims 19-25 depend from claim 18 and are allowable as depending from 
an allowable base claim. These claims are also allowable for their own recited 
features which, in combination with those recited in claim 18, are neither disclosed 
nor suggested in the references of record, either singly or in combination with one 
another. 

In addition, regarding claim 20, the Office argues that Fig. 28 of Maclnnis 
discloses "wherein the filter is a post-processing filter." Applicant, after reviewing 
Fig. 28, fails to see how this subject matter is disclosed or suggested. Specifically, 
Fig. 28 deals with blending by the video compositor, not the accelerator. 
Accordingly, Applicant submits that the Office's reliance on this figure is 
misplaced. 

In addition, regarding claim 23, the Office cites Column 4 (lines 40-51) of 
Maclnnis and argues "the strength parameter is the scaling". Applicant 
respectfully disagrees and submits that the Office has mischaracterized the 
Maclnnis reference. Specifically, this excerpt merely discusses a video scaler that 
is responsible for scaling video stream input. This simply has nothing to do, 
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whatsoever, with "a strength parameter to control an amount of filter applied by a 
receiving filter" or any other parameter(s) "which, when received by the 
accelerator, affects one or more filter settings of the accelerator", as claimed. 

Furthermore, even if "the strength parameter was the scaling", which it is 
not, the office appears to have forgotten that it relies (albeit inappropriately) on the 
"blending, scaling, blitting, and filling" of M&clnnis's graphics accelerator, not its 
video scaler, for disclosing "the filter parameters". As such, the scaling performed 
by the video scaler in Maclnnis could not possibly disclose the strength parameter 
recited in this claim. In addition, even a cursory glance at Fig. 2 of Maclnnis 
illustrates that the Video Scaler 52 is completely separate from the Graphics 
Accelerator 64 and performs a completely different function(s). 

Conclusion 

The Office has failed to establish a prima facie case of obviousness. 
Accordingly, Applicant respectfully requests that the rejections be overturned and 
that the pending claims be allowed to issue. 
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(8) Appendix of Appealed Claims 



1 . (Previously Presented) A method comprising: 

receiving a command from a decoder application at an application program 
interface (API), wherein the API is configured to facilitate the use of a plurality of 
different multimedia accelerators with the decoder application; and 

generating one or more filter control command data structures, recognizable 
by a communicatively coupled accelerator including one or more parameters 
which, when received by the accelerator, affects one or more filter settings of the 
accelerator based, at least in part, on the content of the received command. 

2. (Original) A method according to claim 1, further comprising: 
passing the generated filter control command data structures to the accelerator, 
wherein the accelerator modifies one or more filter settings in accordance with the 
parameters embedded within the data structure. 

3. (Original) A method according to claim 1, wherein the filter is a post- 
processing filter. 

4. (Original) A method according to claim 3, wherein output data 
subsequent to the application of a post-processing filter are used as prediction 
references for decoding subsequent data. 
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5. (Original) A method according to claim 3, wherein the post- 
processing filter is one or more of a deblocking filter, a de-ringing filter, and the 
like. 

6. (Original) A method according to claim 1, wherein the parameters 
include a strength parameter. 

7. (Original) A method according to claim 6, wherein the generated data 
structure includes a strength parameter for each of one or more block boundaries 
of a frame. 

8. (Original) A method according to claim 1, wherein the API issues 
filter control commands for each of a number of edges of luminance and 
chrominance blocks of received media content. 

9. (Original) A method according to claim 1, wherein the API issues 
macroblock filter control command data structures for each macroblock of video 
picture content, each macroblock filter control command comprising four (4) or 
sixteen (16) luminance block filter control command data structures for controlling 
the filtering of the luminance blocks of the macroblock, and/or two (2), four (4), 
eight (8), sixteen (16), or thirty-two (32) chrominance block filter control 
command data structures for controlling the filtering of the chrominance blocks of 
the macroblock. 
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10. (Previously Presented) One or more computer-readable media 
having computer-readable instructions stored thereon which, when executed by a 
computer, implement a method according to claim 1 . 

1 1 . (Previously Presented) A system comprising: 
one or more computer-readable media; and 

computer-readable instructions on the one or more computer-readable 
media which, when executed by one or more processors, implement a method 
according to claim 1 . 

12. (Previously Presented) One or more computer-readable media 
having computer-readable instructions stored thereon which, when executed by a 
computer, implement an application program interface (API) to dynamically 
generate one or more filter control command data structures in response to a 
command received from a decoder application, wherein the one or more filter 
control command data structure(s) include one or more parameters which, when 
received by a communicatively coupled accelerator, effect one or more filter 
settings on the accelerator in accordance with the received command, wherein the 
API is not specific to any particular multimedia application and/or multimedia 
accelerator. 

13. (Original) A storage medium according to claim 12, wherein the 
filter control command data structure(s) effect one or more post processing 
filter(s) of the accelerator. 
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14. (Original) A storage medium according to claim 12, wherein the 
filter control command data structure(s) effect one or more of a deblocking 
filter(s), de-ringing filter(s), and/or another post processing filter of the 
accelerator. 

15. (Original) A storage medium according to claim 12, wherein the 
API issues a filter control command data structure for each of a number of edges 
of luminance and chrominance blocks of received media content. 

16. (Original) A storage medium according to claim 15, wherein the 
API issues four (4) filter control command data structures for each luminance 
block, and/or two (2) filter control command data structure(s) for each 
chrominance block. 

17. (Original) A storage medium according to claim 12, wherein the 
parameter(s) include a filter strength parameter. 

18. (Previously Presented) A computing system comprising: 
a decoder application to process received media content; and 

an operating system including an application program interface (API), 
support the media processing, wherein the API generates one or more filter control 
commands including one or more parameters which, when received by a 
communicatively coupled media processing accelerator, effect one or more filter 
settings of the accelerator in accordance with a command received from the 
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decoder, wherein the decoder application is configured to iteratively issue 
configuration commands reflecting various alternative degrees and methods of 
decoding acceleration capability until choosing one that is acceptable to both the 
decoder application and the accelerator. 

19. (Original) A computing system according to claim 18, further 
comprising: 

one or more media processing accelerator(s), communicatively coupled to 
the decoder application via the API, including one or more filter(s) responsive to 
the filter control command data structures reflecting information received in the 
command from the decoder. 

20. (Original) A computing system according to claim 19, wherein the 
filter(s) are post processing filters. 

21. (Previously Presented) A computing system according to claim 19, 
wherein the filter(s) include one or more of a deblocking filter and de-ringing 
filter. 
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22. (Original) A computing system according to claim 18, wherein the 
API issues macroblock filter control command data structures for each macroblock 
of video picture content, each macroblock filter control command comprising four 
(4) or sixteen (16) luminance block filter control command data structures for 
controlling the filtering of the luminance blocks of the macroblock, and/or two (2), 
four (4), eight (8) , sixteen (16) or thirty-two (32) chrominance block filter control 
command data structures for controlling the filtering of the chrominance blocks of 
the macroblock. 

23. (Original) A computing system according to claim 18, wherein the 
filter control command data structures include a strength parameter to control an 
amount of filter applied by a receiving filter. 

24. (Original) A computing system according to claim 18, further 
comprising: 

a storage medium having stored therein a plurality of executable 
instructions; and 

an execution unit, coupled to the storage medium, to execute at least a 
subset of the plurality of executable instructions to implement the operating 
system and associated API. 
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25. (Original) A computing system according to claim 24, wherein the 
execution unit executes at least a subset of the plurality of executable instructions 
to implement the decoder application. 
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(9) Evidence appendix. None 
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(10) Related proceedings appendix. None 



